Loadstar 248/248.d81/t.about db

Text File | 2022-08-26 | 5KB | 170 lines

u
         BEHIND DOTBASIC PLUS
           by Dave Moorman


    Several years ago, my PC guru,
Kevin Barrow, was taking a course in
Beginning Programming at Lamar
Community College. When I found out
that they were learning Visual Basic
and C, I conned the instructor into
letting me audit the second half of
the course. I wanted to learn C. She
obliged, and even gave me the
textbook.

    I didn't much care for C. The
systax is quite different than BASIC.
And linking and compiling can be a
source of extreme frustration --
especially when a list of Fatal Errors
scrolls up the screen. With a
compiler, you [must] correct fatal
errors before you can find out if you
made any logic errors. Which you
probably have.

    One thing I did find fascinating
about C was the concept of "include."
You see, C is nothing but a shell. The
real work is done by command
libraries, which you must INCLUDE in
your code. There is a nearly infinite
number of such libraries. How to use
one is the $64 question -- that being
the price of the book. Each book. A
nearly infinite number of books.

    One thing about programming the
C-64: we have BASIC built in. We also
have many useable ML routines built
in. And thanks to LOADSTAR, I have
dozens of ML modules such as Mr.Mouse
that greatly extend the power of
BASIC. And all of LOADSTAR's
"includes" are fully documented with
their publication. No extra books!

    Or, if I need some small piece of
code to push around bits and bytes in
a certain and fast way, I have ML
itself. This is where I live quite
comfortably, thank you.

    But Kevin and I got talking late
one night over coffee at the 24-hour
truck stop about what can and can't be
done on the PC as opposed to the C-64.
Assembly object code on the Intel-type
processors is very relocatable. In
fact, the operating system takes care
of memory management for you. With the
C-64 and the 65xx ML instructions, we
are not so fortunate. Most 65xx
instructions require Absolute
Addressing -- that is, when you

 LDA ADDRESS

you must be sure ADDRESS is the right
place in memory. Of course, you can
use ML MOVE by Jeff Jones to relocate
the code. But you still must do some
memory management to know where to
relocate it.

    "What you need," Kevin opined, "is
a module that can be BLOADED anywhere
in memory and work perfectly."

    Thanks, Kevin! We do have Relative
Branch instructions that can leap low
buildings in a single bound (-128 to
+127 bytes). And we do have Indirect
Addressing that uses Zero Page as if
it consists of 128 memory registers.
The Intel- type processors never had
that. (OK, they DO have their way to
do indirect indexed addressing, and
Intel is not a [bad] processor. Heck,
a 400 Mhz+ Pentium will run VICE :-)

    So I got busy and devised MARM --
Moorman's Adaptable Relocatable Module
system. The programmer can use MARM
Maker to collect various commands into
a truly relocatable module. In the
program, the module's load address is
SYSed, and the jump table for the
various commands is placed in the
cassette buffer.

    MARM was a good beginning, but
suffered from lack of forethought. One
routine could not call another, since
the computer had no idea where that
other routine might be, if it was in
memory at all. And multiple routines
could not safely share data. MARM just
had no way to do complexity.

    Then we got on another tack --
creating a Visual Basic for the C-64.
It would need to have Visual Design
and an Event Driven environment. That
meant the programmer would design the
screen first, defining Event Areas
(where clicking would do something)
and assigning line numbers for the
Event Handling routines.

    I am proud that DotBASIC v1 did
both and more, and have turned to it
for a dozen projects. However, having
to design a screen first is a bit of a
pain (not to mention some 18 pages of
memory being used for that screen).
Also, the Event Driver routine could
get in the way of editing the code.
Besides, the limits of my Event Driver
became apparent -- at least to me.

    Besides, DotBASIC v1 did not
address the desire for an adaptable
extension of BASIC. With adaptability,
new commands could be written as
needed. Old commands could be reworked
ad infinitum. And, in theory, the
memory overhead would only be what was
really needed for a particular
program.

    I needed an INCLUDE!

    The problem boiled down to how to
handle the new command names. I
decided to use a table called COMAD,
which would be created to include all
the commands used in a program, along
with the memory locations of the
included commands.

    The relocatable ML routines would
use the same COMAD table when calling
another routine or shared data. Soon I
had DB+ up and working -- and here it
is.

    Take a look at all the information
on Side 4. Even if you are fairly new
at plain old BASIC, DB+ will give you
the power you need to do most anything
computational -- without having to
worry about memory management and
other fine points. Just include the
commands you want -- and away you go!

 DMM